Thanks for posting in our issue tracker.
In order to properly assist you, we need additional information:

• When does the issue occur?
• What do you see?
• What was the expected result?
• Can you supply us with a stacktrace? (optional)
• Do you have exact code to reproduce it? Maybe a PHPUnit tests that fails? (optional)

Thanks!

This is an automated comment, triggered by adding the label status:need more info.

AFAIK, it is also common to use code as prefix or suffix in foreign key column.

In my case, actually we are need to build REST API for a legacy desktop application.
As that application is developed by vendor, we only have authorization to access the database, but not change the database structure (as if changing the foreign key column from supplier_code into supplier_id).

It will be nice, if string code also can be cleaned-up in relation name generation, in addition to string id.
As in my case, the database contains almost 300 tables, which always have code prefix or suffix in its foreign key columns.

When does the issue occur?

August 2017, since at that time we'd just start the REST API development.

What do you see? And what was the expected result?

All relation name which it's foreign key has code prefix or suffix, is generated with Code in it.
For example for foreign key supplier_code, instead of getting getSupplier() for its relation function name, gii generate getSupplierCode()

OK. Got it. I can't say that using code for the purpose is common.

Instead of introducing hardcoded $string_replacements it worth making a list of replacements a property in model generator and leaving its default value to ['id']. This way there will be no false positives and you'll be able to set your own custom replacements via gii config.

@samdark
Thank you so much for your feedback.
Noted. I'll make public property for that.

Please, write unit tests for this case.

@dmirogin, as a matter of fact, at this time, i don't have much experience for writing unit testing yet.
But i would learn it for sure.

Thank you for putting effort in the improvement of the Yii framework.
We have reviewed your pull request.

In order for the framework and your solution to remain stable in the future, we have a unit test requirement in place. Therefore we can only accept your pull request if it is covered by unit tests.

Could you add these please?

Thanks!

P.S. If you have any questions about the creation of unit tests? Don't hesitate to ask for support. More information about unit tests

This is an automated comment, triggered by adding the label pr:request for unit tests.

@samdark these changes might have impact on #417 . was looking through the milestone issues and noticed this. Haven't checked it myself to be sure